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Prufungsantrag gem. § 44 PatG ist gestellt 

@ Verfahren und Kommunikationssystem zur Behandlung von Alarmen durch ein mehrere Managementebenen 
aufweisendes Managementnetz 

(57) Die Erfindung geht davon aus, date fur einen Alarmda- 
tenabgleich zwischen einem Agent (AG) einer Manage- 
mentebene (B, C) und zumindest einem Manager (MA1, 
MA2) einer nachsthoheren Managementebene (A, B) die 
Alarmdaten aktiver Alarme ubertragen werden. Daruber 
hinaus werden von einem Manager (MA1 , MA2) eine oder 
mehrere Anforderungsnachrichten (repAA) zum Ubermit- 
teln der Alarmdaten an den Agent (AG) gesendet, sowie 
Korrelationsinformationen (alaAH, aliNI) fur eine Zuord- 
nung der jeweiligen Anforderung zu den vom Agent (AG) 
nachfolgend gesendeten Nachrichten (aINO) empfangen. 
ErfindungsgemaG wird von dem Manager (MAI, MA2) 
der Alarmdatenabgleich abhangig von zumindest einem 
zum Agent gesendeten Parameter gesteuert. Durch den 
■ Erfindungsgegenstand ist der Alarmdatenabgleich fur 
i den Manager gegenuber der Basisfunktionalitat- Verwen- 
» dung der Korrelationsinformationen - parametrisierbar, d. 
h. nicht mehr alle aktiven Alarme mussen zwangslaufig 
vom Agent gesendet werden, sondern nur die durch den 
ubermittelten Parameter naher definierten. Daraus ergibt 
sich eine optimale Nutzung der Ubertragungsressourcen 
auf der Schnittstelle der Agent-Manager-Beziehung sowie 
ein schnellstmogliches Bereitstelien nur der vom Mana- 
ger gewunschten Alarmdaten durch den Agent. 
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Beschreibung 



Die Erfindung betrifft ein Verfahren sowie ein entspre- 
chendes Kommunikationssy stem zur Behandlung von Alar- 
men durch ein mehrere Managementebenen aufweisendes 
Managementnetz, wobei fur einen Alarrndatenabgleich zwi- 
schen einem Agent einer Managementebene und zuinindest 
einem Manager einer nachsthoheren Managementebene die 
Alarmdaten aktiver Alarme ubertragen werden. 

Die Prinzipien eines Managementnetzes, die auch als 
TMN-Prinzipien (Telecommunications Management Net- 
work) bezeichnet werden, definieren mehrere Management- 
ebenen fur das Management eines Kommunikationssy stems 
- beispielsweise eines Mobil-Kommunikationssystems 
wobei jede Ebene eine doppelte Funktion hat. Im managen- 
den System hat jede Ebene auBer der untersten eine Mana- 
ger- Funktion fur die darunterliegende Ebene, Im gemanag- 
tcn System hat jede Ebcnc auBer der obcrstcn cine Agcntcn- 
Funktion fur die nachsthohere Ebene. 

Das Fehlermanagement ("Fault Management") ist ein 
wichtiger Teil des TMN-Managements. Grundsatzlich spielt 
hier der Agent die aktive Rolle, indem er Fehler der eigenen 
Managementebene rechtzeitig und genau erkennt und an 
den Manager der nachsthoheren Ebene als Alarme ubertragt. 
Die Ubertragung von Alanndalen vom Agenl zurn Manager 
ist unkritisch, solange der Kommunikationsmechanismus 
zwischen diesen Systemen nicht gestort ist. Wenn die Ver- 
bindung zwischen den beiden Managementebenen, also 
zwischen Agent und Manager, fur eine bestimmte Zeit nicht 
mehr gewahrleistet ist, muB der Agent die wahrend dieses 
Intervalls aufgetretenen Alanne zwischenspeichern, um si- 
cherzustellen, daB nach dem Wiederherstellen der Kommu- 
nikationsmoglichkeit dem Manager zurn einen moglichst 
schnell eine Ubersicht der z. Zt. aktiven Alarme z. B. in 
Form einer Liste - zur Verfugung gestellt wird, und der Ma- 
nager zurn anderen eine moglichst liickenlose Alarmge- 
schichte ("alarm history") sowohl der aktiven als auch der 
beendeten Alarme ("cleared alarms") aufbauen kann. 

Zu diesem Zweck wird ein Alarrndatenabgleich (alarm 
realignment) zwischen Agent und Manager bei jedem neuen 
Verbindungsaufbau nach einem Verbindungsabbruch oder 
nach einer Initialisierung des Agenten oder des Managers 
ausgefuhrt. Alle Alarmdaten aktiver Alanne, zu denen Feh- 
ler im Agent noch nicht behoben sind - erkennbar daran, 
daB sie nicht als "cleared alarms" gekennzeichnet sind -, 
sind daher schnellstmoglich und vollstandig der nachsthohe- 
ren Managementebene zur Verfugung zu stellen. 

In der alteren Patentanmeldung P 19752614.4 sind ein 
derartiges Verfahren und Kommunikationssy stem zur Be- 
handlung von Alarmen angegeben, die eine Basisfunktiona- 
litat fur den Manager zur Anforderung aller Alarme vom 
Agent beschrieben. Dabei sendet der Agent die aktiven 
Alarme als Sequenz standardisierter M-EVENT-REPORTS , 
die in eine vom Manager zu Anfang initiierte M-ACTION- 
Request Anforderung und in eine vom Agent zurn Ende in- 
itiierte M-ACTION-Response Antwort eingebettet ist. Die- 
ses sind generische CMISE-standardisierte (Common Ma- 
nagement Information Service Element) Prozeduren, die ge- 
maB ITU-T X.710 definiert sind. Die ITU-T X.733 definiert 
den Inhalt einer standardisierten Alarmubertragung (alarm 
report), die gemaB den M-EVENT-REPORT Services 
durchgefuhrt wird. Alle in Rahmen dieser M-ACTION defi- 
nierten M-EVENT-REPORTS sind zu der jeweiligen Anfor- 
derung durch Verwendung von Korrelationsinformationen 
cindcutig korrclicrt. Dies crlaubt dem Manager, dicsc M- 
E VENT-REPORTS einer bestimmten Anforderung zuzu- 
ordnen und daruber hinaus von anderen, "regularen" M- 
E VENT-REPORTS zu unterscheiden. 



Aufgabe der Erfindung ist es, ein derartiges Verfahren 
und Kommunikationssystem zur Behandlung von Alarmen 
durch ein mehrere Managementebenen aufweisendes Ma- 
nagementnetz anzugeben, durch das ein Alarmdatenab- 
5 gleich zwischen einem Agent und zumindest einem Mana- 
ger weiter verbessert wird. 

Diese Aufgabe wird gemaB der Erfindung hinsichtlich des 
Verfahrens durch die Merkmale des Patentanspruchs 1 und 
hinsichtlich des Kommunikationssystems durch die Merk- 
10 male des Patentanspruchs 12 gelost. Weiterbildungen der 
Erfindung sind den Unteranspriichen zu entnehmen. 

Die Erfindung geht davon aus, daB fur einen Alarrndaten- 
abgleich zwischen einem Agent einer Managementebene 
und zumindest einem Manager einer nachsthoheren Ma- 
15 nagementebene die Alarmdaten aktiver Alanne ubertragen 
werden. Daruber hinaus werden von dem Manager eine oder 
mehrere Anforderungsnachrichten zurn Ubermitteln der 
Alarmdaten an den Agent gesendet, sowic Korrelationsin- 
formationen fur eine Zuordnung der jeweiligen Anforde- 
20 rung zu den vom Agent nachfolgend gesendeten Nachrich- 
ten mit den Alarmdaten empfangen. ErfindungsgemaB wird 
von dem Manager der Alarrndatenabgleich abhangig von 
zumindest einem zum Agent gesendeten Parameter gesteu- 
ert. 

25 Durch den Erfindungsgegenstand ist der Alarrndatenab- 
gleich fur den Manager gegenuber der Basisfunktionalitat 
parametrisierbar, d. h. nicht mehr alle aktiven Alarme miis- 
sen zwangslaufig vom Agent gesendet werden, sondem nur 
die durch den ubermittelten Parameter naher definierten. 
30 Damit ergibt sich fur den Manager eine Auswahlfunktion 
fur eine Teilmenge aus alien Alarmen. Insbesondere die 
Moglichkeit der steuernden Beeinflussung des Abgleichs 
nut einfachen Mitteln und unter Anwendung standardisier- 
ter Nachrichten erhoht die Flexibihtat des Managers und re- 
-35 duziert den Nachrichten- und Informations fluB erheblich. 
Erst durch die parametrisierbare Alignment-Funktionalitat 
gemaB der Erfindung konnen beispielsweise eine Priorisie- 
rung der Alarme und/oder eine aktive Steuerung der Reihen- 
folge der angeforderten Alarme erzielt werden. Besonders 
40 die Kombination der Basisfunktionalitat - Verwendung der 
Korrelationsinformationen - mit der parametrisierbaren 
Alignment-Funktionalitat fuhrt zu einem besonders effekti- 
ven Verfahren und Kommunikationssystem, das eine opti- 
male Nutzung der Ubertragungsressourcen auf der Schnitt- 
45 stelle der Agent-Manager-Beziehung sowie ein schnellst- 
mogliches Bereitstellen nur der vom Manager gewunschten 
Alarmdaten aktiver Alarme fur die nachsthohere Manage- 
mentebene durch den Agent bewirkt. 

GemaB einer Weiterbildung der Erfindung werden von 
50 dem Manager der oder die Parameter in jeder Anforderungs- 
nachricht zu dem Agent gesendet. Dadurch erfolgt die vom 
Manager gewunschte Pararnetrisierung des Alarmdatenab- 
gleichs fur jede einzelne Anforderung individuell. 

GemaB einer alternativen Weiterbildung der Erfindung 
55 werden von dem Manager der oder die Parameter in einer 
den Anforderungsnachrichten vorangestellten Setznachricht 
zu dem Agent gesendet. Dadurch erfolgt die vom Manager 
gewunschte Pararnetrisierung des Alarmdatenabgleichs vor 
der ersten Anforderungsnachricht gemeinsam fur mehrere 
60 Anforderungen, fur die die in der Setznachricht enthaltene 
einmalige Einstellung des Managers Gultigkeit hat. 

GemaB weiterer vorteilhafter Weiterbildungen der Erfin- 
dung kann die Pararnetrisierung mit einem oder mehreren 
der folgenden, von dem Manager jeweils eingestellten Para- 
65 mctcrwcrtcn crfolgcn. Durch den Paramctcrwcrt werden 
vom Agent Alarme angefordert, 



- die von ausgewahlten Agenteinheiten stammen, 
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- fur die eine Dringlichkeit angenommen wird, 

- anhand dessen der Agent eine Priori sierung beim 
Senden der angeforderten Alarme nach deren Dring- 
lichkeit, vorzugsweise anhand unterschiedlicher 
Dringlichkeitswerte, vornimmt, 5 

- die innerhalb eines durch einen Anfangszeitpunkt 
und einen Endzeitpunkt definierten Zeitintervalls ent- 
stehen, 

- anhand dessen der Agent beim Senden eine Priori- 
sierung der Alarme nach dem Entstehungszeitpunkt der 10 
Alarme vornimmt. 

Eine Ausgestaltung des Erfindungsgegenstandes sieht 
vor, daG von dem Agent die Alarmdaten der Alarme mit den 
altesten Entstehungszeitpunkten zuerst und die Alarmdaten 15 
der Alarme mit den jungsten Entstehungszeitpunkten zuletzt 
bereitgestellt und gesendet werden. 

So sicht cine besonders giinstigc Ausgestaltung des Erfin- 
dungsgegenstandes vor, daB von dem Agent die Alarmdaten 
der Alarme mit kritischer Dringlichkeit, bei der die Funktio- 20 
nalitat als nicht mehr gegeben angenommen wird, zuerst 
und die Alarmdaten der Alarme mit unkritischer Dringlich- 
keit, bei der die Funktionalitat als nicht mehr gegeben ange- 
nommen wird, zuletzt bereitgestellt und gesendet werden. 

Mit der obigen Vorgehensweise kann der Manager die im 25 
Hinblick auf die Funktionalitat besonders kritischen und da- 
mit fur ihn wichtigen Alarme gezielt abrufen, und dabei die 
Schnittstelle zum Agent durch den nur auf bestimmte 
Alarme eingeschrankten InformationsfluB gegenuber dem 
herkommlichen Verfahren der automatischen Meldung aller 30 
Alarme wesentiich entlasten. 

Nachstehend wird die Erfindung anhand von Ausfiih- 
rungsbeispielen unter Bezugnahme auf die Figuren naher er- 
lautert. Es zeigen 

Fig. 1 das Blockschaltbild eines Managementnetzes fur 35 
ein Mobil- Kommunikations system mit Agent-Man ager-Be- 
ziehung zwischen einem Betriebs- und Wartungszentrum 
und einem oder mehreren Netzmanagementzentren, 

Fig. 2 das Blockschaltbild des Managementnetzes gemaG 
Fig. 1 mit Agent-Manager-Beziehung zwischen einem Ba- 40 
sisstationssystem und einem Betriebs- und Wartungszen- 
trum zur Durchfuhrung von zumindest zwei Anwendungen 
fur das Basisstationssystem, 

Fig. 3 das Blockschaltbild von Agent und Manager zur 
Behandlung der Alarme fiir parallel oder seriell ablaufende 45 
Alarmdatenabgleiche, 

Fig. 4 den NachrichtenfluB zwischen dem Manager und 
dem Agent zur individuellen parameterabhangigen Steue- 
rung des Alarmdaten abgleichs in jeder Anforderungsnach- 
richt, 50 

Fig. 5 den NachrichtenfluB nach Fig. 4 am Beispiel der 
Verwendung von zwei verschiedenen Parameter werten. 

Fig. 6 den NachrichtenfluB zwischen dem Manager und 
dem Agent zur parameterabhangigen Steuerung des Alarm- 
datenabgleichs durch eine einmaiige Einstellung fur meh- 55 
rere Anforderungsnachrichten. 

Fig. 7 den NachrichtenfluB nach Fig. 6 am Beispiel der 
Verwendung von zwei verschiedenen Parameterwerten, und 

Fig. 8 den NachrichtenfluB zwischen dem Manager und 
dem Agent zur Abfrage der fiir den Alarmdaten abgleich be- 60 
nutzten Parameterwerte nach Fig. 7. 

Das Ausfuhrungsbeispiel beschreibt die Erfindung an- 
hand eines TMN-Konzepts fiir das Management eines Mo- 
bil-Kommunikationssystems, das beispielsweise Netzein- 
richtungen eines Mobilfunknctzcs nach dem GSM- Standard 65 
aufweist. Die Erfindung ist aber nicht auf Mobilfunknetze 
beschrankt, sondern laBt sich auf Telekommunikationsnetze 
jeder Art, die ein TMN-Managementnetz nutzen, anwenden. 



Ein Mobil-Kommunikationssystem ist ein hierarchisch 
gegliedertes System verschiedener Netzeinrichtungen, bei 
dem die unterste Hierarchiestufe von den Mobilstationen 
gebildet wird. Diese Mobilstationen kommunizieren iiber 
eine Funkschnittstelle mit die nachste Hierarchieebene bil- 
denden Funkstationen, die als Basisstationen bezeichnet 
werden. Die beispielsweise Mobilstationen in einem Funk- 
bereich einer Funkzelle versorgenden Basisstationen sind 
vorzugsweise zur Abdeckung eines groGeren Funkgebiets 
zusammengefaBt und mit ubergeordneten Netzeinrichtun- 
gen, den Basisstationssteuerungen verbunden. Die Basissta- 
tionen und Basisstationssteuerungen gehoren zu einem Ba- 
sisstationssystem (Base Station Subsystem) des Mobil- 
Kommunikationssystems. Die Basisstationssteuerungen 
kommunizieren uber definierte Schnittstellen mit einer oder 
mehreren Vermittlungseinrichtungen, den Mobil vermitt- 
lungsstellen, uber die u. a. auch der Ubergang zu anderen 
Kommunikationsnctzcn crfolgt. Die Mobilvcrmittlungsstcl- 
len bilden gemeinsam mit einer Mehrzahl von Datenbanken 
das Vermittlungssystem (Switching Subsystem) des Mobil- 
Kommunikationssystems. 

Neben den obigen Netzeinrichtungen existieren ein oder 
mehrere Betriebs- und Wartungszentren (Operation and 
Maintenance Centers), die u. a. zum Konfigurieren und 
Uberwachen der Netzeinrichtungen dient. Uberwachungs- 
maGnahrnen und KonfigurierungsmaGnahmen werden 
hierzu meist vom Betriebs- und Wartungszentrum aus fern- 
gesteuert die ublicherweise im Bereich der Mobil vermitt- 
lungsstellen angeordnet sind. Ein Betriebs- und Wartungs- 
zentrum kommuniziert dabei jeweils mit einem Basisstati- 
onssystem oder Vermittlungssystem uber eine definierte 
Schnittstelle. Eine weitere Aufgabe des Betriebs- und War- 
tungssystems ist die Durchfuhrung des Konfigurationsma- 
nagements (Configuration Management), das neben dem 
Fehlermanagement einen von fiinf Managementfunktions- 
bereichen darstellt, die die TMN-Prinzipien identifizieren. 
Das Konfigurationsmanagement definiert eine Reihe von 
Diensten, die eine Anderung der Struktur und damit des Ver- 
haltens eines Telekommunikationsnetzes durch den Bedie- 
ner ermoglichen. Diese Dienste beziehen sich imrner auf In- 
stanzen von gemanagten Objekten, die insgesamt die netz- 
spezifische Managementinformationsbasis bilden. 

Ein gemanagtes Objekt im Sinne des Konfigurationsma- 
nagements ist eine logische Abstraktion einer Ressource im 
Mobil-Kommunikationssystem. Hierbei wird unterschieden 
zwischen hardwarebezogenen gemanagten Objekten, die 
eine herstellerspezifische Realisierung einer Funktion be- 
schreiben, und funktionsbezogenen gemanagten Objekten, 
bei denen es sich jeweils um die Abstraktion einer herstel- 
lerunabhangigen Funktionalitat handelt. 

Fiir das Management des Mobil-Kommunikationssy- 
stems definieren die TMN-Prinzipien mehrere Ebenen ("Le- 
vels"), von denen im vorliegenden Beispiel drei Ebenen un- 
ter Bezugnahme auf die Fig. 1 und 2 nachfolgend erlautert 
werden. 

Die Fig. 1 und 2 zeigen jeweils drei Ebenen A, B und C 
des Managementnetzes, von denen die Managementebene C 
die Netzeinrichtungsebene ("Network Element Level") mit 
mehreren Basisstationssystemen BSS11, BSS12 . . . BSS1N 
sowie BSS21, BSS22 ... BSS2M enthalt. Die Manage- 
mentebene B kennzeichnet die Netzeinrichtungsmanage- 
mentebene ("Network Element Management Level"), in der 
Betriebs- und Wartungszentren OMC1 und OMC2 jeweils 
die herstellerspezifische Managementfunktionalitat fur ein- 
zclnc Subsystcmc, wic im vorliegenden Beispiel das Be- 
triebs- und Wartungszentrum OMC1 fur die Basisstarions- 
systeme BSS11, BSS12 . . . BSS1N und das Betriebs- und 
Wartungszentrum OMC2 fiir die Basisstationssysteme 
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BSS21, BSS22 . . . BSS2M, bereitstellen. Die Management- 
ebene A kennzeichnet die Netzmanagementebene ("Net- 
work Management Level"), in der Netzmanagementzentren 
NMC1 und NMC2 jeweils eine integrierte, vom Hersteller 
unabhangige Management-Funktionalitat realisieren. Dabei 
konnen mehrere Netzmanagementzentren einen Zugriff zu 
derselben Netzeinrichtung der nachstniedrigeren Manage- 
mentebene B haben, im vorliegenden Beispiel die Netzma- 
nagementzentren NMC1 und NMC2 der nachsthoheren Ma- 
nagementebene C zum Betriebs- und Wartungszentrum 
OMC1 der nachstniedrigeren Managementebene B. Zwi- 
schen den Netzeinrichtungen unterschiedlicher Manage- 
mentebenen sind definierte Schnittsteilen zur Informations- 
ubertragung vorgesehen. 

Der Unterschied in den Darstellungen gemaB den Fig. 1 
und 2 liegt darin, daB eine Agent-Man ager-Beziehung zur 
Behandlung von Alarmen ftir einen oder mehrere Alarmda- 
tcnabglcichc in Fig. 1 zwischcn dcm Betriebs- und War- 
tungszentrum OMC1 (Agent) undeinem Netzmanagement- 
zentrum NMC1 (Manager) oder mehreren - physikalisch 
getrennten - Netzmanagementzenu-en NMC1, NMC2 (Ma- 
nager) sowie in Fig. 2 zwischen dem Basisstationssystem 
BSS1 1 (Agent) und zwei verschiedenen Anwendungen OF1 
und OF2 (Manager) in dem Betriebs- und Wartungszentrum 
OMC1 oder zwischen dem Betriebs- und Wartungszentrum 
OMC1 (Agent) und zwei verschiedenen Anwendunge n NF1 
und NF2 (Manager) in dem Netzmanagementzentrum 
NMC1 besteht. Um in den Netzmanagementzentren NMC1, 
NMC2 jederzeit einen Uberblick uber die Fehlersituation si 
cherzustellen, werden vom Betriebs- und Wartungszentrum 
OMC1 die-aufGrund von beispielsweise innerhalb der be- 
treuten Basisstationssysteme BSS11 . . . BSS1N auftreten- 
den Fehlern - gespeicherten Alarmdaten aktiver Alarme be- 
reitgestellt und parallel zu beiden Managern auf Anforde- 
rung gesendet. Dies erfolgt vorzugsweise nach einem Ver- 
bindungsabbruch oder nach einer Initialisierung des Agen- 
ten oder des Managers. Ebenso konnen mehrere Anforde- 
rungen auch hintereinander von einem einzelnen Manager, 
z. B. dem Netzmanagementzentrum NMC1 an den Agent, 
z. B. dem Betriebs- und Wartungszentrum OMC1, gerichtet 
werden. Fig. 1 zeigt die Struktur fur gemaB der Erfindung 
mehrfach ausgesendete Anforderungen zum Alarmdatenab- 
gleich, die ini vorliegenden Beispiel parallel zwischen der 
Managementebene B, in der sich der Agent in Form des Be- 
triebs- und Wartungszentrums OMC1 befindet, und der 
nachsthoheren Managementebene A, in der die Manager 
von zumindest zwei Netzmanagementzentren NMC1, 
NMC2 gebildet werden, ablaufen. 

Um auch in der Managementebene B, z. B. in dem Be- 
triebs- und Wartungszentrum OMCl jederzeit einen Uber- 
blick uber die Fehlersituation sicherzustellen, werden vom 
Basisstationssystem BSS11 die - auf Grund von beispiels- 
weise innerhalb der betreuten Basisstationen und Basisstati- 
onssteuerungen auftretenden Fehlern - gespeicherten 
Alarmdaten aktiver Alarme bereitgestelit und parallel zu 
mindestens zwei Managern des Betriebs- und Wartungszen- 
trums OMCl in Form der unterschiedlichen Anwendungen 
OF1 und OF2, die beide von ein- und derselben physikali- 
schen Einrichtung OMCl ausgefuhrt werden, gesendet. 
Dies erfolgt ebenfalls vorzugsweise nach einem Verbin- 
dungsabbruch oder nach einer Initialisierung des Agenten 
oder des Managers. Eine serielle Ubertragung von mehrfach 
durch einen einzelnen Manager, z. B. dem Betriebs- und 
Wartungszentrum OMCl, initiierten Anforderungen an den 
Agent, z. B. dcm Basisstationssystem BSS11, ist ebenfalls 
moglich. Alternativ oder zusatzlich kann eine Agent-Mana- 
ger Beziehung auch zwischen dem Betriebs- und Wartungs- 
zentrum OMCl (ein Agent) und dem Netzmanagementzen- 



trum NMC1 (ein Manager) zum seriellen Austausch von 
Anforderungen und Alarmdaten oder zum parallelen Aus- 
tausch von Anforderungen und Alarmdaten fur mindestens 
zwei unterschiedliche Anwendungen NF1 und NF2 (zwei 
5 Manager) im Netzmanagementzentrum NMC1 existieren. 
Fig. 2 zeigt die Struktur fur gemaB der Erfindung parallel 
ablaufende Alarmdatenabgleiche zwischen der Manage- 
mentebene B, in der sich die Manager als Anwendungen 
OF1 und OF2 befinden, und der nachstniedrigeren Manage- 
to mentebene C, in der sich der Agent befindet. 

Sobald eine in der Managementebene C ausgefallene in- 
terne Schnittstelle wieder betriebsbereit ist, wird auf Anfor- 
derung des Managers/der Manager der Alarmdatenabgleich, 
auch als Realignment-Prozedur oder Realignment- Verfah- 
15 ren bezeichnet, gestartet, wobei gemaB der Erfindung vom 
Manager der Alarmdatenabgleich parameterabhangig ge- 
steuert wird. Dabei beginnt der Alarmdatenabgleich im vor- 
liegenden Beispiel zucrst zwischen dcm Basisstationssy- 
stem, z. B. BSS1 1, und den Anwendungen OF1, OF2 im Be- 
20 triebs- und Wartungszentrum OMCl parallel und setzt sich 
anschlieGend zwischen dem Betriebs- und Wartungszentrum 
OMCl und den iibergeordneten Netzmanagementzentren 
NMC1, NMC2 parallel fort. Am Ende dieser Prozeduren ist 
die Fehlersituation sowohl im OMC als auch in den NMC 
25 wieder aktualisiert. Das Realign men t-Verfahren kann selbst- 
verstandlich auf die Aktualisierung der Alarmdaten zwi- 
schen Agent und Managern in zwei unmittelbar angrenzen- 
den Managementebenen, z. B. Ebene B und Ebene A, be- 
schrankt sein. 

30 Fig. 3 zeigt in schematischer Darstellung den Aufbau von 
Agent AG und Manager MAI, MA2 mit den zur Durchfuh- 
rung simultan - bei zwei oder mehreren Managern - oder 
seriell - bei nur einem Manager - ablaufender Realignment- 
Prozeduren erforderlichen Einrichtungen. Jeder Manager 
35 MAI, MA2 und Agent AG verfiigt uber eine Steuereinrich- 
tung M-CTR bzw. A-CTR, die die Nachrichten fur den 
Alarmdatenabgleich generieren und auswerten konnen. 
Ebenso weisen sie - nicht naher dargestellte - Sende/Emp- 
fangseinrichtungen fur das Versenden und Empfangen der 
40 Nachrichten sowie Speichereinrichtungen fur das Speichern 
der Alarmdaten und anderer Nutz- und Signalisierungsinfor- 
mationen auf. 

Dabei ftigen die Steuereinrichtungen M-CTR der Mana- 
ger MAI, MA2 in die jeweilige Anforderungsnachricht zur 
45 Ubermittlung der Alarmdaten durch den Agent eine zur Zu- 
ordnung der Anforderung zu nachfolgend gesendeten Nach- 
richten benutzte Korrelationsinfonnation ein, die eindeutig 
ist, und veranlaBt die Ubertragung zum Agent. Daruber hin- 
aus fugen die Einrichtungen M-CTR der Manager MAI, 
50 MA2 zur Steuerung des Alarmdaten abgleichs einen oder 
mehrere Parameter par in jede Anforderungsnachricht indi- 
vidual oder in eine den Anforderungsnachrichten vorange- 
stellte Setznachricht ein, um bestimmte, durch verschiedene 
Parameterwerte gekennzeichnete Alarme gezielt anzufor- 
55 dern. Die jeweilige Anforderungsnachricht bzw. die geson- 
derte Setznachricht wird mit den Parametem par zum Agent 
AG gesendet. Erst durch die parametrisierbare Alignment- 
Funktionaiitat gemaB der Erfindung konnen beispielsweise 
eine Priorisierung der Alarme und/oder eine aktive vSteue- 
60 rung der Reihenfolge der angeforderten Alarme erzielt wer- 
den. 

Die Steuereinrichtung A-CTR des Agent AG empfangt 
die entsprechende Nachricht mit den Parametern par, wertet 
sie aus, und startet das Realignment zu den Managern MAI, 
65 MA2 durch Ruckscndcn der von den Managern spczifisch 
angeforderten Alarme. Dabei wird die von den Managern 
MAI, MA2 in die Anforderungsnachricht eingetragene ein- 
deutige Korrelationsinformation zur Korrelation der Anfor- 
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derungen benutzt, und jeweils eine Nachricht mil einer wei- 
teren Korrelationsinformation zur Zuordnung der nachfol- 
gend vom Agent gesendeten Nachrichten (alarm notificati- 
ons) zu dem jeweils gestartelen Realignment in die nachst- 
hohere Managementebene gesendet. Auch die weitere Kor- 5 
relationsinformation ist eindeutig. Durch die Verwendung 
der Korrelationsinformationen ist eine eindeutige Zuord- 
nung simultan oder seriell durchgefuhrter Realignments zu 
mehreren Managern oder einem einzelnen Manager mog- 
lich. io 

Besonders die Kombination der Basisfunktionalitat - Ver- 
wendung der Korrelationsinformationen - mit der parame- 
trisierbaren Alignment-Funkuonalitat fiihrt zu einem beson- 
ders effektiven Verfahren und Kommunikationssystem, das 
eine optimale Nutzung der Ubertragungsressourcen auf der 15 
Schnittstelle der Agent-Manager-Beziehung sowie ein 
schnellstmogliches Bereitstellen nur der vom Manager ge- 
wiinschtcn Alarmdatcn aktivcr Alarme fiir die nachsthohcrc 
Managementebene durch den Agent bewirkt. Ressourcen- 
ausnutzung, Zeitdauer und Flexibility werden folglich in 20 
dem erfindungsgemaB ausgestalteten Kommunikationssy- 
stem gegeniiber der Basisfunktionalitat weiter optirniert. 

Wahlweise konnen im Agent AG mehrere, jeweils den 
Managern MAI, MA2 zuordenbare und von ihnen steuer- 
bare Fillerfunklionen EFD1, EFD2 (Event Forwarding Di- 25 
scriminators) mit Filterkriterien fiir die vom Agent AG er- 
zeugten Nachrichten mitbenutzt werden, sodaB die Nach- 
richten mit den Alarmdaten nur bei Erfullen der Filterkrite- 
rien zu den Managern MAI, MA2 geroutet werden. Die 
Steuereinrichtung M-CTR des Managers ist in der Lage, 30 
derartige Filterfunktionen im Agent AG einzurichten, zu 16- 
schen und die Filterkriterien festzulegen, urn je nach seinen 
individuellen Anforderungen den NachrichtenfluB steuern 
zu konnen. Daher kann der Fall auftreten, daB die Filter- 
funktions-Einstellung von Manager zu Manager unter- 35 
schiedlich ist, sodaB durch die simultan ablaufenden Real- 
ignment- Prozeduren inhaltlich verschiedene Alarme mit zu- 
gehorigen Alarmdaten behandelt werden. 

Fig, 4 zeigt den NachrichtenfluB zwischen einem Agent 
AG - im dargestellten Beispiel gemaB der Fig. 1 dem Be- 40 
triebs- und Wartungszentrum OMC1 oder im dargestellten 
Beispiel der Fig. 2 dem Basisstationssystem BSS11 - und 
dem Manager MAI, MA2 - im Beispiel gemaB der Fig. 1 
den unterschiedlichen Netzmanagementzentren NMC1, 
NMC2 oder im Beispiel der Fig. 2 den verschiedenen App- 45 
likationenOFl,OF2. 

Der NachrichtenfluB erfolgt vorzugsweise unter Verwen- 
dung standardisierter M- EVENT-REPORT Nachrichten, die 
in eine zu Anfang initiierte M-ACTION-Request Anforde- 
rung und in eine zum Ende initiierte M-ACTION-Response 50 
Ant wort eingebettet sind. Dieses sind generische CMISE- 
standardisierte (Common Management Information Service 
Element) Prozeduren, die gemaB ITU-T X.710 definiert 
sind. Die ITU-T X.733 definiert den Inhalt einer standardi- 
sierten Alarmubertragung (alarm report), die gemaB den M- 55 
EVENT-REPORT Services durchgefuhrt wird. Die Korrela- 
tionsinformationen werden in die Nachrichten bzw. in be- 
stimmte Nachrichtenfelder eingetragen. Des weiteren verse- 
hen die Manager MAI, MA2 die Parameter zur Steuerung 
des Alarmdatenabgleichs mit bestimmten Parameterwerten 60 
und tragen sie einzeln oder mehrfach in die jeweilige Anfor- 
derungsnachricht ein. Das Beispiel in Fig. 4 zeigt den Nach- 
richtenfluB nur anhand einzelner Nachrichten, wobei diese 
parallel zwischen dem Agent AG und den Managern MAI, 
MA2 oder scricll zwischen dem Agent AG und dem cinzel- 65 
nen Manager MAI ubertragen werden konnen. 

Sobald nach einer Unterbrechung der Verbindung die 
Kommunikation zwischen dem Manager MAI, MA2 und 
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dem Agent AG wiederhergestellt ist, sender jeder Manager 
MAI, MA2 die M-ACTION-Request Anforderung mit ei- 
ner Anforderungsnachricht repAA (report Active Alarms) 
zum Uberrnitteln der Alarmdaten. Vorzugsweise wird eine 
vom Manager MAI, MA2 definierte Korrelationsinforma- 
tion alaAH (alarm Alignment Handle) - beispielsweise im 
definierten Nachrichtenfeld "actionlnfonnation" - mitge- 
sendet, die eine direkte Zuordnung der aktuellen M-AC- 
TION-Request Anforderung zu alien nachfolgenden Agent- 
Nachrichten kennzeichnet. Damit ist bei mehreren Mana- 
gern die aktuelle Anforderung auch dem jeweiligen Mana- 
ger zuordenbar, sodaB die parallelen Realignments der Ma- 
nager voneinander unabhangig initiiert, durchgefuhrt und 
beendet werden konnen. 

Die Anforderungsnachricht repAA enthalt auch die vom 
Manager eingetragenen Parameterwerte fiir den nachfolgen- 
den Funktionsablauf. Damit wird eine einmalige individu- 
cllc Funktionsausfiihrung (Action) zur paramctcrabhangi- 
gen Ubermittlung von Alarmen vom Agent AG angefordert. 
Die Parametrisierung kann vorzugsweise mit einem oder 
mehreren eingestellten Parameterwerten relEN (related En- 
tities), relPS (related perceived Severity), priSV (prio seve- 
rity), relTT (related Time Interval), priDT (prio Detection 
Time) erfolgen. Durch den spezifischen Parameterwert wer- 
den vom Agent Alarme angefordert, 

- die von ausgewahlten Agenteinheiten stammen (re- 
1EN), 

- fur die eine Dringlichkeit angenommen wird (relPS), 

- anhand dessen der Agent beim Senden eine Priori- 
sierung der angeforderten Alarme nach deren Dring- 
lichkeit, vorzugsweise anhand unterschiedlicher 
Dringlichkeitswerte (priSV), vornimmt, 

die innerhalb eines durch einen Anfangszeitpunkt 
und einen Endzeitpunkt definierten Zeitintervalls ent- 
stehen (relTT), 

- anhand dessen der Agent beim Senden eine Priori- 
sierung der Alarme nach dem Entstehungszeitpunkt der 
Alarme vornimmt (priDT). 

Die Parameterwerte relEN . . . sind in einem gemaB dem 
Standard vorgegebenen Nachrichtenfeld der M-ACTION- 
Request Anforderung enthalten, um bereits vorhandene und 
definierte Felder mitbenutzen zu konnen. Eine gunstige Va- 
riante unter Einbeziehung der Zeit besteht darin, daB von 
dem Agent die Alarmdaten der Alarme mit den altesten Ent- 
stehungszeitpunkten zuerst und die Alarmdaten der Alarme 
mit den jungsten Entstehungszeitpunkten zuietzt bereitge- 
stellt und gesendet werden. Eine besonders geeignete Va- 
riante der Kombination der Parameterwerte beziiglich Zeit 
und Dringlichkeit besteht darin, daB von dem Agent die 
Alarmdaten der Alarme mit kritischer Dringlichkeit, bei der 
die Funktionalitat als nicht mehr gegeben angenommen 
wird, zuerst und die Alarmdaten der Alarme mit unkritischer 
Dringlichkeit, bei der die Funktionalitat als noch gegeben 
angenommen wird, zuietzt bereitgestellt und gesendet wer- 
den. 

Im AnschluB an die Auswertung der Parameter in der ein- 
getroffenen M-ACTION-Request Anforderung und der Be- 
reitstellung nur der Alarmdaten, die zu den vom Manager in 
der parametrisierten Anforderung definierten Alarmen ge- 
horen, startet der Agent AG den Alarmdatenabgleich durch 
Erzeugen einer Nachricht staAA (start Alarm Alignment) 
und Einfugen einer weiteren Korrelationsinformation aliNI 
(alignment Notification Id) in diese Nachricht. Die vom 
Agent AG eingetragene Korrelationsinformation aliNI er- 
moglicht eine direkte Korrelation nachfolgender Alarme zu 
dem jeweils gestarteten Alarmdatenabgleich. Dabei ist die 
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Korrelationsinformation alaAH ebenfails in einem be- 
stimmten Nachrichtenfeld enthalten. Die Korrelationsinfor- 
mation aliNI ist beispielsweise in dem standardisierten 
Nachrichtenfeld "notification Identifier" der Nachrichf. 
staAA eingetragen. Beide Informationen alaAH, aliNI wer- 
den gemeinsam in der Nachricht staAA vom Agent AG zu 
den Managem MAI, MA2 ausgesendet. Dadurch konnen 
"alignmentbezogene" M- EVENT-REPORT Nachrichten 
verschiedener M-ACTTON-Requests voneinander unter- 
schieden werden, aber auch von regularen M-EVENT-RE- 
PORT Nachrichten, die mit dem Datenabgleich nichts zu tun 
haben. Eine Alignment-Prozedur stoppt namlich nicht zwin- 
gend andere M-EVENT-REPORT Nachrichten, die wah- 
rend der Alignment-Prozedur spontan auftreten und an den 
oder die Manager gesendet werden. 

Uber die in der Anforderungsnachricht repAA des M- 
ACTTON-Requests mitgesendete Korrelationsinformation 
alaAH lasscn sich dirckt die folgcndcn Nachrichten staAA 
sowie repAA korrelieren, da sie ebenfails die Korrelations- 
information alaAH enthalten. Die Nachrichten alNO sind 
uber die Korrelationsinformation aliNI mit der Nachricht 
staAA direkt korreliert. Der Manager kann die Anforde- 
rungsnachricht repAA mit den nachfolgenden Nachrichten 
alNO indirekt uber die beiden in der Nachricht staAA ent- 
hallenen Korrelationsinfonnationen alaAH und aliNI korre- 
lieren. 

Im AnschluB an den Start des Alarmdatenabgleichs er- 
folgt die sukzessive Ubertragung der Alarme mit den zuge- 
horigen Alarmdaten in aufeinanderfolgenden Nachrichten 
alNO (alarm notification) unter Verwendung des M- 
EVENT-REPORT Service. Dabei weisen die einzelnen 
Nachrichten alNO jeweils die Korrelationsinformation 
aliNI - beispielsweise in dem definierten Nachrichtenfeld 
"correlated Notifications" auf. Nach der letzten M- 
E VENT-REPORT Nachricht des Alarmdatenabgleichs ge- 
neriert der Agent AG die M-ACTTON-Response Antwort 
zur Nachricht repAA (report Active Alarms), die die Korre- 
lationsinformation alaAH zur eindeutigen Kennung der je- 
weiligen Anforderung des Managers MAI, MA2 enthalt. 
Durch Auswertung dieser Korrelationsinformation kann je- 
der Manager MAI, MA2, das Ende seiner initiierten M-AC- 
TION-Request Anforderung auf einfache Art und Weise er- 
kennen und die eintreffenden Alarmdaten den Anforderun- 
gen zuordnen. Fur den Fall, daB zum Zeitpunkt der M-AC- 
TION-Request Anforderung keine aktiven Alarme gespei- 
chert sind, initiiert der Agent die M-ACTION-Response 
Antwort unmittelbar nach dem Senden der Nachricht 
staAA. Die Korrelationsinfonnationen alaAH, aliNI fur die 
eindeutige Zuordnung mehrerer Anforderungen - moglicher 
simultaner Realignments zu mehreren Managern oder seri- 
eiler Realignments zu einem einzelnen Manager - werden 
dennoch von den in der Agent-Man ager-Beziehung invol- 
vierten Einrichtungen generiert und in den Nachrichten re- 
pAA, staAA gesendet. Auch wenn das zu Fig, 4 beschrie- 
bene Beispiel sich auf parallel Realignments zu mehreren 
Managern bezieht, kann der NachrichtenfluB selbstverstand- 
lich auf mehrere, von einem einzigen Manager nacheinander 
ausgeldste Anforderungen angewendet werden, mit dem 
VorteiL daB durch die eindeutige Zuordnung anhand der 
Korrelationsinfonnationen fur den einzelnen Manager die 
Moglichkeit besteht, die eintreffenden Antworten des Agen- 
ten mit den Alarmdaten auch bei Nichteinhalten derReihen- 
folge eindeutig den Anforderungen zuordnen zu konnen - 
beispielsweise unterschiedlichen Anwendungen im Mana- 
ger. Nacheinander gcscndctc Anforderungen konnen sich 
gegebenenfalls gegenseitig uberholen, beispielsweise dann, 
wenn zwischen Agent und Manager ein Paketnetz durchlau- 
fen wird. 
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Fig, 5 zeigt den NachrichtenfluB gemaB Fig. 4 bei Ver- 
wendung von zwei verschiedenen Pararneterwerten, die im 
vorliegenden Beispiel von den Pararneterwerten priSV und 
relTT gebildet sind. Der Parameterwert priSV nimmt den 
5 Wert TRUE an, was dem Agent signalisiert, daB er bei der 
Sendereihenfolge der Alarme nach unterschiedlichen Dring- 
lichkeits werten priorisieren soli. Fur den Fall, daB der Para- 
meterwert priSV einen anderen Wert (z. B. FALSE) an- 
nimmt, verzichtet der Agent auf die Priorisierung nach 
10 Dringlichkeitswerten. Wird das optional vorhandene Feld 
vom Manager zur Steuerung der angeforderten Alarme erst 
gar nicht benutzt, werden alle aktive Alarme, die eine ange- 
nommen Dringlichkeit aufweisen, ubertragen (default-Mo- 
dus). Der zweite Parameterwert relTI enthalt eine Sequenz 
15 von zwei Werten inst (Interval Start) und inen (Interval 
End), die einen Anfangszeitpunkt und einen Endzeitpunkt 
zur Festlegung eines Zeitintervalls markieren. Dies bedeu- 
tct, daB nur die Alarme vom Agent angefordert werden, die 
innerhalb des durch inst, inen ge ken nzeic line ten Zeitinter- 
20 vails entstehen. Wird das optional vorhandene Feld vom 
Manager zur Steuerung der angeforderten Alarme erst gar 
nicht benutzt, werden aile aktive Alarme ohne Berucksichti- 
gung des Entstehungszeitpunkts ubertragen (default-Mo- 
dus). Im vorliegenden Beispiel werden gezielt nur die 
25 Alarme - priorisierl nach deren Dringlichkeit (siehe obige 
Ausfuhrungen) -, die zwischen "inst = 12.01.98 10:15:00" 
und "inen = 12.01.98 11:15:00" auftreten, vom Agent zur 
Verfiigung gestellt und zum Manager gesendet. 

GemaB dem Beispiel in Fig. 5 werden in den auf die 
30 Nachricht staAA folgenden Nachrichten alNO die Alarmda- 
ten der ausgewahlten Alarme unter Verwendung des M- 
EVENT-REPORT Service gesendet. Die einzelnen Nach- 
richten alNO weisen neben der Korrelationsinformation 
aliNI einen Wert fur die Dringlichkeit SV (perceived Seve- 
35 rity) des Alarms und einen Entstehungszeitpunkt evT (event 
Time) des Alarms auf. Die unterschiedlichen Dringlich- 
keitswerte reichen von "kritisch" cri (critical) uber "wichtig" 
maj (major), "weniger wichtig" min (minor) bis zu "unkri- 
tisch" war (warning). Als kritisch wird ein Alarm aufgefasst, 
40 bei der die Funktionalitat als nicht mehr gegeben angenom- 
men wird, wahrend bei einem unkritischen Alarm die Funk- 
tionalitat als noch gegeben angenommen wird. Empfangt 
der Manager den Dringlichkeitswert war, fasst er diesen 
Alarm als Warnung bezuglich einer moglichen Beeintrachti- 
45 gung der Funktionen des Agent auf. 

Durch die eingestellten Parameter bezuglich der Dring- 
lichkeit und des vom Agent zu uberprufenden Zeitintervalls 
weisen die beiden zuerst ges endeten Nachrichten alNO die 
Werte S V=cri fur das Vorliegen kritischer Dringlichkeit mit 
50 zugehdrigen Werten evT = 10:50:30 und evT = 10:20:20 fur 
die Zeitpunkte ihres Auftretens. Die beiden nachstfolgenden 
Nachrichten alNO enthalten die Werte SV=maj, evT = 
10:25:50 zur Kennzeichnung eines Alarms mit einer wichti- 
gen Dringlichkeit und die Werte SV=min, evT = 10:22:10 
55 zur Kennzeichnung eines Alarms mit einer weniger wichti- 
gen Dringlichkeit. Die im Beispiel zuletzt gesendete Nach- 
richt alNO umfasst die Werte SV=war, evT =10:17:30, ent- 
sprechend der Anzeige einer Warnung an den Manager. Die 
Nachrichtensequenz ist fur das individuelle Anfordern be- 
60 stimrnter Alarme durch Einstellung der Parameter in jeder 
Anforderungsnachricht repAA geeignet. 

Im Gegensatz zu der Einstellung pro M-ACTION Re- 
quest Anforderung zeigt Fig. 6 den NachrichtenfluB zwi- 
schen dem Manager und dem Agent zur parameterabhangi- 
65 gen Steuerung des Alarmdatenabgleichs durch cine cinma- 
lige Einstellung der Parameter, die fur mehrere anschlie- 
Bende Anforderungsnachrichten repAA Gultigkeit hat. Da- 
mit wird in vorteilhafter Weise eine Parametrisierung fur 
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den Alarmdatenabgleich erzielt, ohne daB es jedes Mai einer 
Neueinstellung der Parameter bedarf. Zu diesem Zweck ist 
den Anforderungsnachrichten repAA gemaB M- ACTION 
Request, von denen bei spiel haft nur eine dargestellt ist, eine 
Nachricht M-SET vorangestellt, mit der der oder die vom 5 
Manager eingefiigten Parameter relEN, relPS, priSV, relTI, 
priDT im Agent als Auswahlkriterien fur die zu ubertragen- 
den Alanne gesetzt werden. 

Fig. 7 zeigt den zur Vorgehensweise von Fig. 6 gehorigen 
NachrichtenfluB bei Einstellung der zu Fig. 5 bereits be- to 
schriebenen beiden Parameter priSV, relTT. Im Unterschied 
zu Fig. 5 werden das durch den Anfangszeitpunkt inst und 
den Endezeitpunkt inen festgelegte Zeitintervall als Pararne- 
terwert relTI -nur in diesem Zeitfenster sollen vom Agent 
Alarme registriert und nach Dringlichkeit priorisiert werden 15 
- und die Dringlichkeit als Pararneterwert priS V vom Mana- 
ger in die Setznachricht M-SET eingefugt und vorab zum 
Agent gesendct. Die Einstcllungcn bchaltcn fiir allc darauf- 
folgenden Anforderungsnachrichten ihre Gultigkeit, bis eine 
neue Setznachricht M-SET die bisherigen Parameter liber- 20 
schreibt oder fiir ungiiltig erklart. Die Nachrichten alNO 
enthalten dieselben Parameter werte, die in Fig. 5 beispiel- 
haft angegeben und laut den zugehorigen Ausfuhrungen be- 
schrieben sind. 

Fig. 8 zeigt den NachrichtenfluB zwischen dem Manager 25 
und dem Agent zur Abfrage der fiir den Alarmdatenabgleich 
benutzten und im Agent eingestellten Parameterwerte nach 
Fig. 7, die mit der vorab gesendeten Setznachricht an den 
Agent ubermittelt wurden. Zu diesem Zweck generiert der 
Manager eine M-GET Request Anforderung mit den abzu- 30 
fragenden Parameterwerten - im Beispiel den Parameter- 
werten priSV, relTT - und sendet sie zum Agent. Als Ant- 
wort erhalt der anfragende Manager eine Nachricht M-GET 
Response mit den im Agent aktuell gultigen Einstellungen 
fiir die vorgegebenen Parameterwerte. Im vorliegenden Bei- 35 
spiel besteht die Riickmeldung des Agent in der Nachricht 
M-GET response aus den Werten priSV=TRUE und relTI 
(inst = 12.01.98 10:15:00, inen = 12.01.98 11:15:00). Auf 
diese Weise kann der Manager uberpriifen, welche aktuelle 
Einstellung vorliegt, um ggf. Anderungen beim spateren 40 
Anfordern bestimmter Alarme durch aufeinanderfolgendes 
Erzeugen und Senden von Anforderungsnachrichten zu tati- 
gen. 

Patentanspriiche 45 

1. Verfahren zur Behandlung von Alarmen in einem 
Kommunikationssystem durch ein mehrere Manage- 
mentebenen (A, B, C) aufweisendes Managementnetz, 
wobei fur einen Alarmdatenabgleich zwischen einem 50 
Agent (AG) einer Managementebene (B, C) und zu- 
mindest einem Manager (MAI, MA2) einer nachstho- 
heren Managementebene (A, B) die Alarmdaten akti- 
ver Alarme ubertragen werden, bei dem 

- von dem Manager (MAI, MA2) jeweils eine 55 
oder mehrere Anforderungsnachrichten (repAA) 
zum Ubermitteln der Alarmdaten an den Agent 
(AG) gesendet werden, 

- von dem Manager (MAI, MA2) Korrelations- 
informationen (alaAH, aliNI) fiir eine Zuordnung 60 
der jeweiligen Anforderung zu den vom Agent 
(AG) nachfolgend gesendeten Nachrichten 
(alNO) mit den Alarmdaten empfangen werden, 
und 

- von dem Manager (MAI, MA2) der Alarmda- 65 
tenabgleich abhangig von zumindest einem zum 
Agent (AG) gesendeten Parameter (par) gesteuert 
wird. 
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2. Verfahren nach Anspruch 1, bei dem von dem Ma- 
nager (MAI, MA2) der oder die Parameter (par) in je- 
der Anforderungsnachricht (repAA) zu dem Agent 
(AG) gesendet werden. 

3. Verfahren nach Anspruch 1, bei dem von dem Ma- 
nager (MAI, MA2) der oder die Parameter (par) in ei- 
ner den Anforderungsnachrichten (repAA) vorange- 
stellt en Setznachricht (M-SET) zu dem Agent (AG) ge- 
sendet werden. 

4. Verfahren nach einem der vorhergehenden Ansprii- 
che, bei dem ein Parameter (par) von dem Manager 
(MAI, MA2) mit einem Pararneterwert (relEN) verse- 
hen wird, durch den vom Agent (AG) Alarme angefor- 
dert werden, die von ausgewahlten Agenteinheiten 
stammen. 

5. Verfahren nach einem der vorhergehenden Ansprii- 
che, bei dem ein Parameter (par) von dem Manager 
(MAI, MA2) mit einem Pararneterwert (re IPS) vcrsc- 
hen wird, durch den vom Agent (AG) Alarme angefor- 
dert werden, fur die eine Dringlichkeit angenommen 
wird. 

6. Verfahren nach Anspruch 5, bei dem von dem Ma- 
nager (MAI, MA2) ein zusatzlicher Pararneterwert 
(priPS) benutzt wird, anhand des sen der Agent (AG) 
beim Senden eine Priorisierung der angeforderlen 
Alarme nach deren Dringlichkeit vornimmt. 

7. Verfahren nach Anspruch 6, bei dem der Agent 
(AG) die Priorisierung der zu dem Manager (MAI, 
MA2) zu ubertragenden Alarme nach unterschiedli- 
chen Dringlichkeitswerten (cri, maj, min, war) vor- 
nimmt. 

8. Verfahren nach einem der vorhergehenden Anspru- 
che, bei dem ein Parameter (par) von dem Manager 
(MAI, MA2) mit einem Pararneterwert (relTT) verse- 
hen wird, durch den vom Agent (AG) Alarme angefor- 
dert werden, die innerhalb eines durch einen Anfangs- 
zeitpunkt (inst) und einen Endzeitpunkt (inen) definier- 
ten Zeitintervalls entstehen. 

9. Verfahren nach einem der vorhergehenden Ansprii- 
che, bei dem von dem Manager (MAI, MA2) ein zu- 
satzlicher Pararneterwert (priDT) benutzt wird, anhand 
dessen der Agent (AG) beim Senden eine Priorisierung 
der Alarme nach dem Entstehungszeitpunkt (evT) der 
Alarme vornimmt. 

10. Verfahren nach Anspruch 9, bei dem von dem 
Agent (AG) die Alarmdaten der Alarme mit den alte- 
sten Entstehungszeitpunkten (evT) zuerst und die 
Alarmdaten der Alarme mit den jungsten Entstehungs- 
zeitpunkten (evT) zuletzt bereitgestellt und gesendet 
werden. 

11. Verfahren nach Anspruch 9 oder 10, bei dem von 
dem Agent (AG) die Alarmdaten der Alarme mit kriti- 
scher Dringlichkeit, bei der die Funktionalitat als nicht 
mehr gegeben angenommen wird, zuerst und die 
Alarmdaten der Alarme mit unkritischer Dringlichkeit, 
bei der die Funktionalitat als noch gegeben angenom- 
men wird, zuletzt bereitgestellt und gesendet werden. 

12. Kommunikationssystem zur Behandlung von 
Alarmen durch ein mehrere Managementebenen (A, B, 
C) aufweisendes Managementnetz, wobei fur einen 
Alarmdatenabgleich zwischen einem Agent (AG) einer 
Managementebene (z. B. B) und zumindest einem Ma- 
nager (MAI, MA2) einer nachsthoheren Management- 
ebene (z. B. A) die Alarmdaten aktiver Alarme ubertra- 
gen werden, 

— Einrichtungen (M-CTR) in dem Manager 
(MAI, MA2) fur das Senden einer oder mehrerer 
Anforderungsnachrichten (rep A A) zum Ubermit- 
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teln der Alarmdaten an den Agent (OMC1), und 

- Einrichtungen (M-CTR) in dem Manager 
(MAI, MA2) fur das Empfangen von Korrelati- 
onsinformationen (alaAH, aliNT) fur eine Zuord- 
nung der jeweiligen Anforderung zu den vom 5 
Agent (AG) nachfolgend gesendeten Nachrichten 
(alNO) mit den Alarmdaten, und 

- Einrichtungen (M-CTR) in dem Manager 
(MAI, MA2) fiir eine Steuerung des Alarmdaten- 
abgleich abhangig von zumindest einem zurn 10 
Agent (AG) gesendeten Parameter (par). 

13. Kommunikationssystem nach Anspruch 12, bei 
dem die Einrichtungen (M-CTR) in dem Manager 
(MAI, MA 2) den oder die Parameter (par) in jede An- 
forderungsnachricht (rep A A) einfugen. 15 

14. Kommunikationssystem nach Anspruch 12, bei 
dem die Einrichtungen (M-CTR) in dem Manager 
(MAI, MA2) den oder die Parameter (par) in cine den 
Anforderungsnachrichten (repAA) vorangestellte, zu 
dem Agent (AG) gesendete Setznachricht (M-SET) 20 
einfugen. 

15. Kommunikationssystem nach einem der Ansprii- 
che 12 bis 14, bei dem von dem Manager (MAI, MA2) 
ein Parameter (par) mit einem Parameterwert (relEN) 
versehen ist, durch den vom Agent (AG) Alarme ange- 25 
fordert werden, die von ausgewahlten Agenteinheiten 
stammen. 

16. Kommunikationssystem nach einem der Anspru- 
che 12 bis 15, bei dem ein Parameter (par) von dem 
Manager (MAI, MA2) mit einem Parameterwert 30 
(relPS) versehen ist, durch-den vom Agent (AG) 
Alarme angefordert werden, fiir die eine Dringlichkeit 
angenommen wird. 

17. Kommunikationssystem nach Anspruch 16, bei 
dem von dem Manager (MAI, MA2) ein zusatzlicher 35 
Parameterwert (priPS) benutzt ist, anhand dessen der 
Agent (AG) beim Senden eine Priorisierung der ange- 
forderten Alarme nach deren Dringlichkeit vornimmt. 

18. Kommunikationssystem nach einem der Anspru- 
che 12 bis 17, bei dem ein Parameter (par) von dem 40 
Manager (MAI, MA2) mit einem Parameterwert 
(relTI) versehen ist, durch den vom Agent (AG) 
Alarme angefordert werden, die innerhalb eines durch 
einen Anfangszeitpunkt (inst) und einen Endzeitpunkt 
(inen) definierten Zeitintervalls entstehen. 45 

19. Kommunikationssystem nach Anspruch 18, bei 
dem von dem Manager (MAI, MA2) ein zusatzlicher 
Parameterwert (priDT) benutzt ist, anhand dessen der 
Agent (AG) eine Priorisierung beim Senden der 
Alarme nach dem Entstehungszeitpunkt (evT) der 50 
Alarme vornimmt. 
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